Throw ValueError when 1 is provided to the second argument of log()#19370
Throw ValueError when 1 is provided to the second argument of log()#19370alexandre-daubois wants to merge 1 commit intophp:masterfrom
log()#19370Conversation
alexandre-daubois
force-pushed
the
log-base-1
branch
from
36f4140 to
755ddc6
Compare
alexandre-daubois
force-pushed
the
log-base-1
branch
from
755ddc6 to
8c5c508
Compare
alexandre-daubois
force-pushed
the
log-base-1
branch
from
8c5c508 to
964eff5
Compare
bukka
left a comment
bukka
left a comment
There was a problem hiding this comment.
Seems like a BC break to me so this might need at least some discussion. Not sure if NaN is worse than exception.
| if (base <= 0.0 || base == 1.0) { | ||
| zend_argument_value_error(2, "must not be 1 or less than or equal to 0"); |
There was a problem hiding this comment.
I would split it to two independent messages if we decide to do it.
|
I understand, I would also be fine throwing a deprecation for now |
alexandre-daubois
force-pushed
the
log-base-1
branch
from
964eff5 to
9f3d5ca
Compare
|
I removed this proposition from https://wiki.php.net/rfc/deprecations_php_8_6, rebased and added an |
|
Not sure if this falls into the same category. Returning |
|
Alright, let's wait for new inputs and I'll add it back to the RFC if there's no news in the coming weeks |
NaN explicitly exists so that one does not need to check each intermediate value. Specifically with floats experiencing implicit rounding, it's not always easy or cheap to avoid specific "malformed" inputs in a chain of operations (vs some class of inputs, such as "all negative numbers" that are reasonable to check for). Trying to diverge from principle goes against the intentional design of IEEE 754 and I would suggest this not be done (and not even put to vote). |
4 participants
This helps with early error detection and explicit intent, instead of having a potential NaN propagating.